Device Decision to Download Software Update

ABSTRACT

Various embodiments that pertain to device software is described. A decision can be made by a device on if the device should download an update for device software, such as a software patch. When the device decides that it should download the update, the device can download the appropriate update. In one example, the update can be downloaded by way of a patch portal that communicates with a patch database. The device can request the patch for the software and in response the device can be provided access to the patch by way of the patch portal.

CROSS-REFERENCE

This application is a continuation of, and claims priority to, U.S.application Ser. No. 16/860,445 filed on Apr. 28, 2020 with U.S. Pat.No. 11,334,344. U.S. application Ser. No. 16/860,445 is herebyincorporated by reference.

GOVERNMENT INTEREST

The innovation described herein may be manufactured, used, imported,sold, and licensed by or for the Government of the United States ofAmerica without the payment of any royalty thereon or therefor.

BACKGROUND

A manufacture can produce a device embedded with software. The softwarecan enable the device to perform various functions. However, due to avariety of reasons such as consumer feedback or further development, thesoftware can become outdated. Therefore, it may be beneficial to updatedevice software.

SUMMARY

In one embodiment, a processor is communicatively coupled to anon-transitory computer-readable medium and is configured to execute acommand set stored by the non-transitory computer-readable medium toeffectuate operation of a component set. The component set can comprisea decision component configured to decide if a download should occur foran update set to a software set on a device. The component set can alsocomprise a download component configured to cause the download to occurin response to the decision component deciding that the download shouldoccur. The non-transitory computer-readable medium and the processor canbe resident upon the device.

In another embodiment, a system can comprise a non-transitorycomputer-readable medium configured to retain a patch database thatcomprises a first patch for a first software module and a second patchfor a second software module. The system can also comprise a receptioncomponent configured to receive a request for the first patch for thefirst software module from the device. The system can additionallycomprise an access component configured to allow access to the firstpatch for the first software module to the device in response to therequest.

In a further embodiment, a system can comprise a non-transitorycomputer-readable medium configured to retain a software registry for adevice, where the software registry lists a first software module of thedevice and a second software module of the device. In addition, thesystem can comprise an update component configured to manage an updatefor the first software module and the second software module through useof the software registry. The update component can manage the update bydownloading a first patch for the first software module and downloadinga second patch for the second patch module. The non-transitorycomputer-readable medium and the update component can be resident uponthe device.

BRIEF DESCRIPTION OF THE DRAWINGS

Incorporated herein are drawings that constitute a part of thespecification and illustrate embodiments of the detailed description.The detailed description will now be described further with reference tothe accompanying drawings as follows:

FIG. 1 illustrates one embodiment of a system comprising a centralrepository, a patch portal, and a device;

FIG. 2 illustrates one embodiment of a manager and the device;

FIG. 3 illustrates one embodiment of the central repository, the patchportal, and three devices;

FIG. 4 illustrates one embodiment of a system comprising a processor anda computer-readable medium;

FIG. 5 illustrates one embodiment of a method comprising two actions;

FIG. 6 illustrates one embodiment of a method comprising seven actions;

FIG. 7 illustrates one embodiment of a method comprising two actions;

FIG. 8 illustrates one embodiment of a method comprising four actions;

FIG. 9 illustrates one embodiment of a method comprising seven actions;and

FIG. 10 illustrates one embodiment of a method comprising five actions.

DETAILED DESCRIPTION

In one environment, a central server system can push patches down toindividual network entities. This top-down approach can have benefits inthat the individual network entities can be up to date as quickly aspossible. While in some contexts this approach can be beneficial, inothers it may not.

Therefore, a bottom-up approach can be practiced. In this, when theindividual entity determines that it should be patched, then thepatching can occur, such as downloading a patch or installing the patch.This can be based on various contexts, such as when the individualentity is not busy, when the individual entity has sufficient networkcapabilities, or when the individual entity is not performing a criticaltask.

The following includes definitions of selected terms employed herein.The definitions include various examples. The examples are not intendedto be limiting.

“One embodiment”, “an embodiment”, “one example”, “an example”, and soon, indicate that the embodiment(s) or example(s) can include aparticular feature, structure, characteristic, property, or element, butthat not every embodiment or example necessarily includes thatparticular feature, structure, characteristic, property, or element.Furthermore, repeated use of the phrase “in one embodiment” may or maynot refer to the same embodiment.

“Computer-readable medium”, as used herein, refers to a medium thatstores signals, instructions and/or data. Examples of acomputer-readable medium include, but are not limited to, non-volatilemedia and volatile media. Non-volatile media may include, for example,optical disks, magnetic disks, and so on. Volatile media may include,for example, semiconductor memories, dynamic memory, and so on. Commonforms of a computer-readable medium may include, but are not limited to,a floppy disk, a flexible disk, a hard disk, a magnetic tape, othermagnetic medium, other optical medium, a Random Access Memory (RAM), aRead-Only Memory (ROM), a memory chip or card, a memory stick, and othermedia from which a computer, a processor or other electronic device canread. In one embodiment, the computer-readable medium is anon-transitory computer-readable medium.

“Component”, as used herein, includes but is not limited to hardware,firmware, software stored on a computer-readable medium or in executionon a machine, and/or combinations of each to perform a function(s) or anaction(s), and/or to cause a function or action from another component,method, and/or system. Component may include a software controlledmicroprocessor, a discrete component, an analog circuit, a digitalcircuit, a programmed logic device, a memory device containinginstructions, and so on. Where multiple components are described, it maybe possible to incorporate the multiple components into one physicalcomponent or conversely, where a single component is described, it maybe possible to distribute that single component between multiplecomponents.

“Software”, as used herein, includes but is not limited to, one or moreexecutable instructions stored on a computer-readable medium that causea computer, processor, or other electronic device to perform functions,actions and/or behave in a desired manner. The instructions may beembodied in various forms including routines, algorithms, modules,methods, threads, and/or programs, including separate applications orcode from dynamically linked libraries.

FIG. 1 illustrates one embodiment of a system 100 comprising a centralrepository 110, a patch portal 120, and a device 130. A centralrepository 110 can retain a group of patches for different softwareapplications. The central repository 110 can make these patchesavailable by way of the patch portal 120. The device 130 can access thepatch portal 120 and download patches to itself from the centralrepository 110.

FIG. 2 illustrates one embodiment of a manager 210 and the device 130.The device 130 can communicate with the manager 210. The manager 210 canmanage the central repository 110 of FIG. 1 and/or the patch portal 120of FIG. 1. This can allow the device 130 to access an appropriate patchor other related data.

The device 130 can retain a processor 220 along with its ownnon-transitory computer-readable medium and the processor 220 can beconfigured to execute a command set to effectuate operation of acomponent set 230. The component set 230 can comprise various componentswith regard to functionality of the device 130. Example components ofthe component set 230 can include a decision component, a downloadcomponent, an assessment component, a determination component, aninterface component, an authentication component, an instillationcomponent, or a combination thereof.

The decision component can decide if a download should occur for anupdate set to a software set on the device. In response to the decisioncomponent deciding the download should occur, the download component cancause the download to occur. If not, then download can be delayed or notoccur. Various contexts can factor into the decision component'sdecision.

In one embodiment, the decision is based, at least in part, on a qualityof a network connection of the device 130. The assessment component canmake an assessment of the quality of the network connection of thedevice 130. The determination component can make a determination if thenetwork connection is of a sufficient quality in relation to a networkconnection quality threshold. If the determination is that the networkconnection is of the sufficient quality, then the decision componentdecides that download should occur; if the determination is that thenetwork connection is not of the sufficient quality, then the decisioncomponent decides that download should not occur.

In one example, the device can be a military radio running software. Thesoftware can be outdated and benefit from a patch. However, the soldiercan be deployed to a remote location, such as mountainous terrain withpoor network connectivity. Due to this poor network connectivity, thedevice 130 can decide that despite a network connection being available,it is not strong enough to warrant patching at that time. Therefore, thedecision component can decide not to download the patch or dataassociated with the patch.

In another embodiment, this can pertain to anticipated networkfunctioning as part of the quality of the network connection. In oneexample, the device 130 could be part of a financial institution andstore important financial information. Due to the sensitivity of thefinancial information, the device 130 can have limited network access,such as ten minutes every twenty-four hours to check for updates. If thedownload will take longer than ten minutes, then the decision componentcan manage for proper download (e.g., work to establish a longer windowso download can occur or manage download across multiple windows).

In one embodiment, the decision is based, at least in part, on a taskschedule of the device 130, such as current or planned operation. Theassessment component can make an assessment of a task schedule of thedevice 130. The decision component can decide if the download shouldoccur based, at least in part, on a result of the assessment.

In one example, the device 130 can be a specific and/or critical device,such as piece of surgical equipment that provides visual information toa surgeon. It may be ill-timed for the device 130 to update duringsurgery as an update may necessitate a restart or may cause loss offunctionality. For a lifesaving surgery or major surgery such as heartsurgery, it can be deemed more important that the device 130 remainfully operational rather than be updated. This can also pertain tofuture operation, such a download that is estimated to take an hour, butthe device is scheduled for use in a half hour. Similarly, if the device130 is part of an emergency room, then the download can be delayed untilthe device 130 is removed from that setting—even if not currently in usethe device 130 could be employed at any moment and therefore a partialor incomplete download could be damaging.

Download management of the device 130 can be user-based. The interfacecomponent can receive a user update request, such as by way of agraphical user interface of the device 130. The authentication componentcan authenticate the user update request to produce an authenticationresult. The decision component can decide that the download should occurin response to the authentication result indicating that the user updaterequest is properly authenticated.

In one example, a user of the device can request for patch download andinstallation to occur. This can be done without any indication to theuser that the patch is available. The authentication component canauthenticate the identity of the user as part of the user updaterequest, such as by password, token, a public key infrastructureidentifier, or biometric indicator (e.g., fingerprint). Theauthentication can also authenticate, as part of the user updaterequest, authenticating the context of the request, such as checking afunction of the device to authenticate the user update request. As anexample of this, the user can request download, but if the networkconnectivity is poor, the authentication can fail.

While aspects discussed above pertain to downloading, they can also beapplied to installation. The installation component can cause theinstallation of the update set upon the update set after the download iscaused. However, various checks can be performed before instillationoccurs upon the device 130.

In one example, the device 130 can be a self-driving vehicle driving ona highway. Network connectivity can be good, so the decision componentcan decide to download a patch and the download component can cause thepatch to download. However, while the self-driving vehicle is drivingdown the highway, it can be an inopportune time to install the patch,especially if such a patch requires a reboot. Therefore, theinstillation component can decide when instillation should occur afterdownload (e.g., at least partial download), such as through artificialintelligence inference or user direction by way of the interfacecomponent.

Returning to discussion of the download, the decision component candecide an order of download for the update set. The download componentcan cause the download to occur in accordance with the order ofdownload. In one example, the update set can comprise two patches—alarger patch and a smaller patch. If the device 130 has a longerexpected window of network connectivity, then the larger patch can bedownloaded first and if the device has a shorter expected window, thenthe smaller patch can be downloaded first. In another example, theupdate set can comprise two patches—a security patch and a featurepatch. The security patch can be downloaded first (or installed first)to the device 130 in view of its presumably higher priority within theupdate set.

The device 130 can retain patch information and install loaded patcheswhen appropriate. With this, the decision component can decide if afirst download should occur for a first update set to a software set onthe device. The first update set can be a patch update set (e.g.,patches themselves). In response to the decision component deciding thefirst download should occur for the first update set, the downloadcomponent can cause the download to occur of the first update set to thedevice 130. The decision component can decide if a second downloadshould occur for a second update set to the software set on the device130 and if so, the download component can cause the second download tooccur. The second update set can be a metadata update set that indicatesa useable portion of the patch update set to perform patching

In one example, when the device 130 has time a number of patch files canbe downloaded as the first update set. In this example, the patch filesare patch portions one through ten. A user can then take the device 130into a remote environment, such as the device that is a navigation toolfor a hiker. When the hiker comes to an area with at least someconnectivity, a metadata file as the second update set can be downloadedand indicates that the device operating system should be patched withpatch portions two and six. The device 130 can then be updated withpatch portions two and six in accordance with the metadata update. Thesecond update set can be much smaller than the first update set, as anindication of what patch portions to use can be much smaller than thepatch portions themselves.

The manager 210 can facilitate the patches being supplied to the device130. The manager can employ a computer-readable medium 240 (e.g.,non-transitory computer readable medium) that retains a patch database.The computer-readable medium 240 can function as the central repository110 of FIG. 1. The patch database can store a first patch for a firstsoftware module and a second patch for a second software module.

The reception component 250 can receive a request for the first patchfor the first software module. The device 130 can send the request. Thedevice 130 can send the request in an encrypted manner for securitypurposes.

The access component 260 can allow access to the first patch for thefirst software module to the device 130 in response to the request andtherefore function as the patch portal 120 of FIG. 1 (e.g., along withthe reception component 250). This access can allow extraction by thedevice 130 as well as the manager sending the first patch to the device130. Additionally, while the device 130 can access the first softwaremodule, the device 130 can facilitate access of the first softwaremodule to another device.

FIG. 3 illustrates one embodiment of the central repository 110, thepatch portal 120, and three devices 130A (device A), 130B (device B),and 130C (device C). The devices 130A-C can be the same device (e.g.,each be radios) or different devices (e.g., one be a smartphone, one bea laptop computer, and one be a tablet). Here, multiple devices 130A-Crun different software modules—some shared, such as the devices 130A and130B running the first software module, and some not, such as the device130B being the only one to run the third software module.

In one example, the device 130B can download the first software patchand not the second software patch since it runs the first softwaremodule, but not the second software module. Similarly, the device 130Acan download the first software patch and not the second software patcheven though it includes both associated modules. That can be an exampleof when the device 130A does not have time for both patches and it isdeemed more important by the device 130A to download the first patchover the second patch. The request can be simply for the first softwarepatch, so the access component 260 of FIG. 2 can allow access to thefirst software patch without allowing access to the second softwarepatch.

In one embodiment, the request from device 130A can be for the firstpatch and the second patch. The device 130A can be allowed access to acommon patch portion that is applicable for the first patch and thesecond patch. The device 130A can download the common patch to itselfafter access is granted.

As discussed above, the central repository can retain various patchportions. For example, the first software patch can comprise a firstpatch portion and a second patch portion while the second software patchcan comprise the first patch portion and a third patch portion. Thedevice 130A can be given access to the first patch portion since it is acommon patch portion applicable for the first software patch and thesecond software patch.

As can be seen in FIG. 3, multiple devices can access the centralrepository 110 and the patch portal 120. With this, the receptioncomponent 250 of FIG. 2 can receive a first request for the firstsoftware patch and the second software patch from the device 130A and asecond request for the second software patch and the fourth softwarepatch from the device 130C. The access component can allow access to thesecond and fourth software patches to the device 130C concurrently withallowing access to the first and second software patches to the device130A. This allows for different devices to have access to the samepatches and different patches concurrently.

FIG. 4 illustrates one embodiment of a system 400 comprising theprocessor 220 and the computer-readable medium 240 (e.g., non-transitorycomputer-readable medium). In one embodiment, the computer-readablemedium 240 is communicatively coupled to the processor 220 and stores acommand set executable by the processor 220 to facilitate operation ofat least one component disclosed herein (e.g., an update component). Inone embodiment, at least one component disclosed herein (e.g., thedecision component and/or the download component discussed above) can beimplemented, at least in part, by way of non-software, such asimplemented as hardware by way of the system 400. In one embodiment, thecomputer-readable medium 240 is configured to store processor-executableinstructions that when executed by the processor 220, cause theprocessor 220 to perform at least part of a method disclosed herein(e.g., at least part of one of the methods 500-1000 discussed below).

FIG. 5 illustrates one embodiment of a method 500 comprising two actions510-520. At 510, an electronic device can download a patch set for theelectronic device. At 520, the downloaded patch set can be used to causean update to the electronic device such that software of the electronicdevice is updated.

FIG. 6 illustrates one embodiment of a method 600 comprising sevenactions 610-670. At 610, a condition of the electronic device can bedetermined, such as a network connectivity level of the electronicdevice or the usage of the electronic device. At 620, a check can occuron if software updates should be downloaded. The check 620 can be basedon a result of the condition determination from 610. If the check 620decides that download should not occur, then at 630 download can fail tooccur. With this, the method 600 can return to 610 for conditionupdates.

If the check 620 determines that download should occur, then at 640 thedownload can take place. Another check can occur at 650 to determine ifupdate should occur. In one embodiment, the check 650 employs a resultfrom action 610 and the decision can be not to update at 660 or toupdate at 670. In one example, the usage of the electronic device can beirrelevant to download as that may not impact the usage, but performingthe update with the download can impact the usage so the decision can befor the update not to be performed.

FIG. 7 illustrates one embodiment of a method 700 comprising two actions710-720. At 710, a software registry for the electronic device (e.g.,device 130A of FIG. 3) can be retained, such as by the computer readablemedium 240 of FIG. 4. The software registry can list a first softwaremodule of the electronic device and a second software module of theelectronic device. At 720, an update for the first software module andthe second software module can be managed through use of the softwareregistry, such as by the update component discussed above with regard toFIG. 4 or an update component that is part of the component set 230 ofFIG. 2. Management of the update can include downloading a first patchfor the first software module and downloading a second patch for thesecond patch module.

FIG. 8 illustrates one embodiment of a method 800 comprising fouractions 710-720 and 810-820. At 710 the software registry can beretained and at 810 a metadata set can be communicated to a managemententity (e.g., the manager 210 of FIG. 2), with the metadata setindicating what software and what version the electronic device isrunning. At 820, a response to the metadata set can be received and beemployed to manage the update at 720. A transmission component can sendthe metadata set and a reception component can receive the response. Thetransmission component and reception component can be effectuated by thesystem 400 of FIG. 4, such as be instructions stored on the samecomputer-readable medium 240 that stores the software registry.

The software registry can list a current device version of the firstsoftware module of the electronic device and a current device version ofthe second software module of the electronic device. A comparison can bedone at 820 of the current versions against available versions. If aversion mismatch exists, then a version update can occur.

In one embodiment, the response is a version list received in responseto the communication of the metadata set. The version list can beemployed to manage the update of the software modules upon theelectronic device at 720. The metadata set can comprise metadata thatpertains to the first software module and the second software module.The version list can comprise metadata that indicates the availableversion of the first software module and the available version of thesecond software module.

In one example, the first software module is at version 1.01 and thesecond software module is at version 1.01. The response received at 820can indicate that the first software module has version 1.01 availableand the second software module has version 1.02 available. In responseto this, at 720, the software patch to update the second software moduleto version 1.02 can be downloaded and/or installed.

In an instillation example, the electronic device can already have whatis appropriate to perform the patch and the version list indicates notonly the version of individual modules, but how to patch the software tothe current version. The electronic device can check if it has what isappropriate to perform the patch, if not, then the electronic device candownload what it is missing to perform the patch.

In one embodiment, the response is an update file received in responseto the communication of the metadata set. The electronic device can sendthe metadata set indicating the software run by the electronic deviceand the manager 210 of FIG. 2 can determine if the software is out ofdate (e.g., an old version is run). In response to this, the manager 210of FIG. 2 can send the update file that includes a patch to update thesoftware so it is no longer out of date.

The software registry can be a device's snapshot of the software moduleversions it retains. The software registry in of itself can be treatedlike a software module. A software patch can be multiple files for aspecific software module. A specific software module can also comprisemultiple software patches. Further, to install a new version it may beappropriate to uninstall a previous version. The software registry orother metadata can indicate when this is appropriate.

FIG. 9 illustrates one embodiment of a method 900 comprising sevenactions 710-720 and 910-950. At 710 the software registry is retainedand then a set of checks can occur. The checks can be run by a decisioncomponent of the electronic device to determine if the update shouldoccur. When the decision component determines that an update shouldoccur based on a result of the checks, then the update can be caused totake place.

At 910, a network connection status of the electronic device candetermined and at 920 a check can occur if the network connection issufficient for the update. If the connection is not sufficient, then themethod 900 can stop at 930 and download does not take place. However, ifthe connection is sufficient, then the method can continue to 940 todetermine an active performance function of the device. Another checkcan occur at 950 on if it is a good time to download. If the check 950determines that it is not a good time to download, then the method cango to 930 to not download. If the check 950 determines that it is a goodtime, then the update can be managed at 720.

While illustrated as a series of checks, it is to be appreciated thatthe checks can be run, at least in part, concurrently. Additionally,while network connectivity and the active performance function (e.g.,current usage of the electronic device such as active in surgery) arediscussed as factors in determining if an update should occur, these arenot limiting. In one example, the storage space available on theelectronic device can determine if download and/or installation of anupdate set should occur.

FIG. 10 illustrates one embodiment of a method 1000 comprising fiveactions 1010-1050. At 1010, the electronic device can enter a highbandwidth environment. Since there is high bandwidth, the electronicdevice can download a patch set at 1020 that can be used to patchsoftware of the electronic device. At 1030, the device can enter a lowbandwidth environment, such as after the patch set is successfullydownloaded. In one example, action 1030 occurs well after action 1010,such as several days or weeks later. While in the low bandwidthenvironment, the electronic device can download the metadata file thatis significantly smaller than the patch set. In view of the metadatafile, the electronic device can install the appropriate patch at 1050.

While the methods disclosed herein are shown and described as a seriesof blocks, it is to be appreciated by one of ordinary skill in the artthat the methods are not restricted by the order of the blocks, as someblocks can take place in different orders.

What is claimed is:
 1. A processor that is communicatively coupled to anon-transitory computer-readable medium and that is configured toexecute a command set stored by the non-transitory computer-readablemedium to effectuate operation of a component set, the component setcomprising: a decision component configured to decide if a downloadshould occur for an update set to a software set on a device; and adownload component configured to cause the download to occur in responseto the decision component deciding that the download should occur, wherethe non-transitory computer-readable medium and the processor areresident upon the device.
 2. The processor of claim 1, the component setcomprising: an assessment component configured to make an assessment ofa quality of a network connection of the device; and a determinationcomponent configured to make a determination if the network is of asufficient quality in relation to a network connection qualitythreshold, where if the determination is that the network is of thesufficient quality, then the decision component decides that downloadshould occur, where if the determination is that the network is not ofthe sufficient quality, then the decision component decides thatdownload should not occur, and where the assessment component and thedetermination component are resident upon the device.
 3. The processorof claim 1, the component set comprising: an assessment componentconfigured to make an assessment of a task schedule of the device, wherethe decision component decides if the download should occur based, atleast in part, on a result of the assessment and where the assessmentcomponent is resident upon the device.
 4. The processor of claim 1, thecomponent set comprising: an interface component configured to receive auser update request; and an authentication component configured toauthenticate the user update request to produce an authenticationresult, where the decision component decides that the download shouldoccur in response to the authentication result indicating that the userupdate request is properly authenticated and where the interfacecomponent and the authentication component are resident upon the device.5. The processor of claim 1, the component set comprising: aninstallation component configured to cause the installation of theupdate set upon the update set after the download is caused, where theinstillation component is resident upon the device.
 6. The processor ofclaim 1, where the decision component is configured to decide an orderof download for the update set and where the download component isconfigured to cause the download to occur in accordance with the orderof download.
 7. The processor of claim 1, where the update set is afirst update set, where the download is a first download, where thedecision component is configured to decide if a second download shouldoccur for a second update set to the software set on the device; wherethe first update set is a patch update set, and where the second updateset is a metadata update set that indicates a useable portion of thepatch update set to perform a patch.
 8. A system, comprising: anon-transitory computer-readable medium configured to retain a patchdatabase that comprises a first patch for a first software module and asecond patch for a second software module; a reception componentconfigured to receive a request for the first patch for the firstsoftware module from the device; and an access component configured toallow access to the first patch for the first software module to thedevice in response to the request.
 9. The system of claim 8, where inhaving access to the first patch the device downloads the first patch toitself, where the device runs the first software module, and where thedevice does not run the second software module.
 10. The system of claim8, where in having access to the first patch the device downloads thefirst patch to itself, where the device runs the first software module,where the device runs the second software module, and where the accesscomponent is configured to allow access to the first patch withoutallowing access to the second patch.
 11. The system of claim 8, wherethe request is a request for the first patch and the second patch, wherethe device is configured to be allowed access to a common patch portionthat is applicable for the first patch and the second patch, and wherethe device downloads the common patch portion to itself after access isgranted.
 12. The system of claim 8, where the request is a firstrequest, where the device is a first device, where the first request isreceived from the first device, where the reception component isconfigured to receive a second request for the second patch for thesecond software module, where the second request is received from asecond device, where the second device is different from the firstdevice, and where the access component is configured to allow access tothe second patch for the second software module to the second device inresponse to the second request concurrently with allowing access to thefirst patch for the first software module to the first device inresponse to the first request.
 13. The system of claim 8, where therequest is a first request, where the device is a first device, wherethe first request is received from the first device, where the receptioncomponent is configured to receive a second request for the first patchfor the first software module, where the second request is received froma second device, where the second device is different from the firstdevice, and where the access component is configured to allow access tothe first patch for the first software module to the second device inresponse to the second request concurrently with allowing access to thefirst patch for the first software module to the first device inresponse to the first request.
 14. A system, comprising: anon-transitory computer-readable medium configured to retain a softwareregistry for a device, where the software registry lists a firstsoftware module of the device and a second software module of thedevice; and an update component configured to manage an update for thefirst software module and the second software module through use of thesoftware registry, where the update component manages the update bydownloading a first patch for the first software module and downloadinga second patch for the second patch module and where the non-transitorycomputer-readable medium and the update component are resident upon thedevice.
 15. The system of claim 14, where the software registry lists acurrent device version of the first software module of the device and acurrent device version of the second software module of the device,where the current device version of the first software module iscompared against an available version of the first software module todetermine if a first software module version mismatch exists, where theupdate causes the current device version of the first software module tobe replaced with the available version of the first software module whenthe first software module version mismatch exists, where the currentdevice version of the software module is compared against an availableversion of the second software module to determine if a second softwaremodule version mismatch exists, and where the update causes the currentdevice version of the second software module to be replaced with theavailable version of the second software module when the first softwaremodule version mismatch exists.
 16. The system of claim 15, comprising:a transmission component configured to communicate a metadata set to amanagement entity, a reception component configured to receive a versionlist in response to the communication of the metadata set, where themetadata set comprises metadata that pertains to the first softwaremodule and the second software module, where the version list comprisesmetadata that indicates the available version of the first softwaremodule and the available version of the second software module, andwhere the update component employs the version list to manage theupdate.
 17. The system of claim 15, comprising: a transmission componentconfigured to communicate a metadata set to a management entity, areception component configured to receive an update file in response tothe communication of the metadata set, where the update file comprisesthe available version of the first software module when the firstsoftware module version mismatch exists, where the update file comprisesthe available version of the second software module when the secondsoftware module version mismatch exists, and where the update componentemploys the update file to manage the update.
 18. The system of claim14, comprising: a decision component configured to make a decision on ifthe update should occur, where the update component manages the updateby causing the update to occur when the decision is that the updateshould occur.
 19. The system of claim 18, where the decision is based,at least in part, on a network connection status of the device.
 20. Thesystem of claim 18, where the decision is based, at least in part, on anactive performance function of the device.